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About This Manual 


This manual is intended to help managers and technical personnel evaluate IBM’s 
Systems Application Architecture, and do some preliminary, high-level planning for 


its implementation. More detailed information will be available in individual refer- 
ence manuals. 
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Part One: Introduction 


Systems Application Architecture 


Background 


What It Covers 


IBM offers systems based on several different hardware architectures and control 
programs. By pursuing a multiple-architecture strategy, IBM has been able to 
provide products with outstanding price/performance ratios across an ever- 
broadening spectrum of customer requirements. Today, IBM’s systems span a 
nearly thousand-fold capacity range, and support the information processing needs 
of people in very different environments. 


To make movement between these systems easier, to facilitate multi-system use, 
and to bring the breadth of IBM’s product line to bear on customers’ needs in all 
environments, IBM has introduced Systems Application Architecture. The results 
of Systems Application Architecture are intended to be: 


e Programming skills that have broader applicability 
e Applications that can be ported with less effort, or that can span systems 


e User access to these applications that is simpler and more uniform. 


Systems Application Architecture is a collection of selected software interfaces, 
conventions, and protocols that will be published in 1987. Systems Application 
Architecture will be the framework for development of consistent applications 
across the future offerings of the three major IBM computing environments: 


e System/370 (TSO/E under MVS/XA, and CMS under VM) 
e System/3X 


¢ Personal Computer (Operating System/2 ™).1 


These interfaces, conventions, and protocols are designed to provide an enhanced 
level of consistency in the following areas: 


¢ Programming interface — the languages and services that application devel- 
Opers use in building their software 


e User access — the use of screen panels, keyboard layouts, display options, and 
other interaction tools and techniques 


¢ Communications support — the connectivity of systems and programs 


¢ Applications — software built and supplied by IBM and other vendors. 


1 Operating System/2 is a trademark of the IBM Corporation. 
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S stem/370 : 





Figure 1. Large Enterprises Seek Multi-System Solutions 


How It Gives Value 
Systems Application Architecture will facilitate an increased level of consistency 
across the participating systems. As a result, the development and use of applica- 
tions should be: 


e Less expensive 
¢ More timely. 


Those users who need access to data on one system today and another system 

tomorrow can benefit. The programs they run are similar, and the actions they 

perform while running those programs are more uniform. Screens, keyboards, 

procedures — their appearance and behavior will often be the same. With less 

relearning, users have faster and easier access to data, and business efficiency 
increases. 


Programmers, too, benefit from this increased consistency. Skills learned in one 
environment are transferrable to others, and there is less need for retraining or for 
system specialists. A programmer familiar with one environment can readily move 
to another and soon be productive. 
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Consistency means portability, and building applications for multi-system solutions 
becomes faster and easier. The source for a program built on one system can be 
taken to another system and implemented more smoothly. The effort expended in 
creating a general data processing solution is therefore lessened, along with 
development time. 


Thus, there is much value in the growing consistency of the interface to the 
System/370, System/3X, and Personal Computer. The people who build the appli- 
cations and the people who use the applications will all benefit. 


In addition to these new benefits, in each of the Systems Application Architecture 
environments IBM plans to continue to support the execution of existing applica- 
tions, thus conserving customers’ current investments. 


System/370 System/3X Personal Computer 





Figure 2. Consistency across Systems 
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Common Programming Interface 


As has been noted, one important part of Systems Application Architecture is a 
common programming interface — the languages, commands, and calls that pro- 
grammers employ. The components of the interface fall into two general catego- 
ries, as follows: 


e Languages 


Application Generator 
C 

COBOL 

FORTRAN 

Procedures Language 


e Services 


Database Interface 
Dialog Interface 
Presentation Interface 
Query Interface 


Specifications for Consistency 
For each component of this programming interface, IBM is establishing a defi- 
nition, or specification. A number of existing IBM products are already aligned 
with these specifications. More importantly, each specification will be used within 
IBM to promote and control software development and facilitate the consistency of 
all future products within the Systems Application Architecture framework. Those 
portions of the products controlled by the Common Programming Interface specifi- 
cations are intended to have consistent implementation on the participating 
systems. 


These IBM specifications have generally been developed with regard for estab- 
lished industry standards. Part Two of this manual (page 20) gives more detail on 
the content of each specification. 


Advantages for Independent Software Vendors 
Just as these specifications will be advantageous for the customers who use IBM 
software to build their own applications, they will benefit the software companies 
who build applications to sell. Using the common programming interfaces to IBM 
products, these companies can more easily design applications suitable for all the 
supported systems. 


Customers seeking to reduce their data processing backlogs with prebuilt applica- 
tions will also benefit, because the vendors will be able to produce applications 
more quickly and cost effectively. 


Full Implementation, Plus 
Over time, it is IBM’s intent to supply products within Systems Application Archi- 
tecture that will fully implement the interface specifications. In addition, some pro- 
ducts may go beyond this to offer extensions that exploit features of the operating 
system or hardware on which they run. 
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When an application is being created for more than one system, its designers and 

coders can stay within the boundaries of the IBM specifications and obtain easier 

portability. If they want to create a program that takes advantage of one particular 
system, they can make use of that product’s unique features. The choice is avail- 

able. 


System/370 Product 


System/3X Product 


Personal Computer Product 


1BM Specification for Interface Component 





Figure 3. Products Will Meet or Exceed the Specification 


Scope 
The interface specifications cover many aspects of a programmer’s interaction with 
selected IBM software. Other aspects will not immediately participate in this com- 
monality. Things such as installation procedures, tuning considerations, and 
compile-time and run-time options are particular to individual products. Further- 
more, other facets of the programming task, such as the use of job control lan- 
guage, will continue to be specific to operating systems and hardware, and remain 
outside the scope of the initial specifications. 


Using the Programming Components Together 
The components for which IBM specifications have been established offer a broad 
span of function that can meet most data processing needs. 


Each component of the interface, as provided by applicable IBM products, is a val- 
uable and efficient data processing aid in itself. Each is a tool that can be used on 
its own to get work done. In addition, many of these interface components can also 
be used together to create larger, more complex applications that accomplish 
sophisticated ends. 
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For example, an integrated application could be built from a combination of appli- 
cation generator and COBOL programs. Commands or queries could be incorpo- 
rated into a FORTRAN program to obtain information from a data base. A program 
written in C could process data and then utilize the presentation interface to show 
results in a graphic format. Procedures language and the dialog interface could be 
used to tie together a multi-step application built of various program parts. The 
possibilities are many. 


Because these components span the spectrum of common application needs, they 
offer the assistance customers require — whether to do a programming job using a 
single component, or to build a more complex data processing solution using mul- 
tiple components of the commmon programming interface. And on top of this, of 
course, they offer all the value of cross-system consistency. 
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Common User Access 


The Common User Access defines the specifications for the dialog between the 
human and the computer. It establishes how information appears on a display 
screen, and how people respond to that information. It includes definitions of inter- 
face elements and rules for interaction techniques such as panels, procedures for 
moving from one panel to another, choice selection, color and emphasis, mes- 
sages, help, and terminology. 


The Common User Access consolidates the latest technology in interface elements 
and techniques. Based on a foundation of fundamental concepts, and designed 
from the top down, its principles will apply across the range of Systems Application 
Architecture systems. 


The Common User Access provides several advantages. Because it incorporates 
superior technology, it is by definition easier to learn and use. And because it is 
consistent across the participating systems, it has the benefits of familiarity. Users 
moving from application to application or from system to system need less time to 
adapt. And the programmers who create and maintain these applications should 
also be able to do so more quickly and easily — both in building the user interface 
portions of the applications, and in using the computer themselves. 


Elements of the Interface 
An interface between user and computer has three main components: 


e The way the machine communicates with the user 
e The way the user communicates with the machine 
¢ What the user understands about the interface. 


The first aspect is what the user perceives, what face the program and the hard- 
ware show to the person at the workstation, how the instructions and data are pre- 
sented. The user has to recognize this information, understand it, and come up 
with an appropriate response. This response, consisting of established actions 
such as key selection or mouse movement, is the second aspect of the interface. 


The third aspect, how users understand this entire process, is really part of the first 
two. Users’ perceptions and expectations — their “conceptual models” — are influ- 
enced by their previous experience. To the extent that the interface is aligned with 
these expectations, it will be easy to use. To the extent that the interface is inte- 
grated and has a good overail design, it will be easy to learn. 


The specifications being established for the Common User Access are intended to 
accomplish both these ends. They set forth a consistent set of concepts that are 
readily acquired and that provide continuity from application to application, system 
to system. 


An interface can be consistent with respect to three broad categories or dimen- 
sions: physical, syntactical, and semantical. 


¢ Physical consistency refers to the hardware: the keyboard layout, the location 
of keys, and the use of the mouse. For example, it would be physically con- 
sistent for the function keys to be in the same place on the keyboard regard- 
less of the system being used. Likewise, it would be physically consistent for 
button 1 on a mouse to always select an item. 
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Flexibility 


Evolution 


e Syntactical consistency refers to the sequence and order of appearance of ele- 
ments on the display screen (the presentation language) and the sequence of 
keystrokes to request actions (the actions language). For example, it would be 
syntactically consistent to always center the panel title at the top of the panel. 


¢ Semantic consistency refers to the meaning of the elements that make up the 
interface. For example, it would be semantically consistent for the command 
SAVE to have the same meaning (what is saved and what happens next) on ail 
systems. 


An interface for user access is dependent on device capabilities. An interface 
designed for an intelligent workstation will not have the same dynamic features as 
one for a less-sophisticated mainframe terminal. Thus, the design of a common 
user interface requires a balance between the desire for consistency and the 
desire for full exploitation of technological capabilities. 


Although the Common User Access lays down rules for interface elements and 
interactions, it gives application designers a fair degree of flexibility. The Common 
User Access defines a number of types of panels and acknowledges that designers 
might require other, application-specific panel types not defined by the Common 
User Access. The Common User Access recommends that programmers try to use 
the defined panels but, if they can’t, to use the common components of defined 
panels. 


The Common User Access is still evolving. It is being created for intelligent work- 
stations and will grow through the midrange systems to the mainframe systems. 
The workstation was chosen as the starting point because it provides the greatest 
dynamic capabilities for the interface. 


When the initial level of the Common User Access has been completely defined, 
those IBM specifications will be published and made generally available, and 
writing applications that follow these specifications will be encouraged. 


In the future, the Common User Access will define added elements and interaction 
techniques as technologies evoive. 


Summary of Benefits 


A defined, common user interface benefits the user and the programmer. For both, 
the benefits are the same: saving time and money. 


Users should benefit because they will need less time to learn how to use an appli- 
cation and, when using the application, take less time doing their work. A con- 
sistent interface also reduces users’ frustration levels and makes them feel more 
comfortable. 


A consistent user interface also benefits application designers and programmers. 
The Common User Access defines building blocks for an interface through speci- 
fied interface elements and interaction techniques. These building blocks allow 
programmers to create and change applications more quickly and easily. 
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Common Communications Support 


Types of Support 


Data Streams 


Common Communications Support is used to connect applications, systems, net- 
works, and devices. This will be achieved by the consistent implementation of des- 
ignated communication architectures in each of the Systems Application 
Architecture environments. These communication architectures are the building 
blocks for distributed function to be detailed in future announcements of the 
Common Programming Interface and IBM-provided Systems Application Architec- 
ture applications. 


The architectures selected to date have been chosen from Systems Network Archi- 
tecture (SNA) and international standards. Each was also included in the Open 
Communication Architectures announcement of September 16, 1986 (Announce- 
ment Letter 286-410), thus reaffirming IBM’s commitment to openness. 


Included in Common Communications Support at this time are data streams, appli- 
cation services, sessions services, network, and data link controls. The aspects of 
each of these are described below. 


The 3270 Data Stream consists of user-provided data and commands, as well as 
control information that governs the way data is handled and formatted by IBM dis- 
plays and printers. The Systems Application Architecture computing environments 
will all support the 3270 Data Stream. In addition, the System/3X family will con- 
tinue to support the 5250 Data Stream. The 3270 Data Stream is documented in 
IBM 3270 Information Display System Data Stream Programmer’s Reference, 
GA23-0059. 


Document Content Architecture (DCA) defines the rules for specifying the form and 
meaning of a text document. It provides for uniform interchange of textual informa- 
tion in the office environment and consists of format elements optimized for docu- 
ment revision. This is documented in Document Content Architecture: 
Revisable-Form-Text Reference, SC23-0758. 


Intelligent Printer Data Stream (IPDS) is the high-function data stream intended for 
use with all-points-addressable page printers. Documentation of this data stream 
will be available shortly. 


Application Services 


SNA Distribution Services (SNADS) provides an asynchronous distribution capa- 
bility in an SNA network, thereby avoiding the need for active sessions between 
the end points. SNADS is documented in SNA Architecture Format and Protocol 
Reference Manual: Distribution Services, SC30-3098. 


Document Interchange Architecture (DIA) provides a set of protocols that define 
several common office functions performed cooperatively by IBM products. This is 
documented in Document Interchange Architecture: Technical Reference, 
$C23-0781. 


SNA Network Management Architecture describes IBM’s approach to managing 
communication networks. The protocols of problem management offer a vehicle 
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Session Services 


Network 


Data Link Controls 


for monitoring network operations from a central location. This is documented in 
SNA Format and Protocol Reference Manual Management Services, SC30-3346. 


LU Type 6.2 is a program-to-program communication protocol. It defines a rich set 
of interprogram communication services, including a base and optional supple- 
mentary services. Support of the base is included in all IBM LU 6.2 products that 
expose an LU 6.2 application programming interface. This facilitates compatibility 
of communication functions across systems. LU 6.2 is documented in SNA Format 
and Protocol Reference Manual: Architecture Logic for LU Type 6.2, SC30-3269. 


Low-Entry Networking Nodes (Type 2.1 Nodes) support peer-to-peer communi- 
cation. Type 2.1 nodes can be either programmable or fixed function systems. 
SNA Low-Entry Networking allows, through a common set of protocols, multiple 
and parallel SNA sessions to be established between Type 2.1 nodes that are 
directly attached to each other. Low-Entry Networking is documented in SNA 
Format and Protocol Reference Manual: Architecture Logic for Type 2.1 Nodes, 
$C30-3422. 


Synchronous Data Link Control (SDLC) is a discipline for managing synchronous, 
code-transparent, serial-by-bit information transfer between nodes that are joined 
by telecommunication links. This is documented in /BM Synchronous Data Link 
Control Concepts, GA27-3093. 


Token-Ring Network consists of a wiring system, a set of communication adapters 
(stations), and an access protocol that controls the sharing of the physical medium 
by the stations attached to the LAN. The IBM Token-Ring Architecture is based on 
the IEEE 802.2 and 802.5 standards. This is documented in Token-Ring Network 
Architecture Reference (part number 6165877). 


X.25 defines a packet-mode interface for attaching data terminal equipment (DTE) 
such as host computers, communication controllers, and terminals to packet- 
switched data networks. An IBM-defined external specification, The X.25 Interface 
for Attaching SNA Nodes to Packet-Switched Data Networks: General Information 
Manual (GA27-3345), and the 1984 version of this interface (GA27-3761), describe 
the elements of CCITT X.25 that are applicable to IBM SNA products that can attach 
to X.25 networks. X.25 is shown here as a data link control to reflect its implemen- 
tation within SNA. In the OSI Reference Model, X.25 is one of the options available 
for the physical, data link, and network layers. 


Current Product Base 


Most of the Common Communications Support architectures are already supported 
in the Systems Application Architecture environments. In MVS and VM, support is 
available through the following product sets: 


Print Services Facility (PSF) 

Graphical Data Display Manager (GDDM) 

Netview 

Virtual Telecommunications Access Method (ACF/VTAM) 
Network Control Program (ACF/NCP) 
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In IBM Operating System/2, the architectures are supported primarily in the Com- 
munications Manager portion of the Enhanced Edition 1.1, and in the applications 
that use the Communications Manager services. 


Future offerings of the System/3X will support the Common Communications 
Support protocols and interfaces. In the current System/36 and System/38 offer- 
ings, support is available throught the following product sets: 


DisplayWrite/36 

Personal Services/36 

System/36 Office Management System 

System/36 System Support Program and Communications Features 

Personal Services/38 

System/38 Control Program Facility and Communications Management Func- 
tions 


Through communications networking and, in particular, through the Common Com- 
munications Support elements, existing applications developed for the current ver- 
sions of the major IBM computing environments will be able to interact with 
applications, functions, and data in the Systems Application Architecture environ- 
ments. This conserves current application investment in existing systems. 


Expansion 
Extensions to the above products and new Systems Application Architecture 
announcements for Common Applications will complete the product support for 
these Common Communications Support architectures in these environments. 


As IBM expands the Systems Application Architecture, additional communications 
architectures will be evaluated for inclusion in Common Communications Support. 
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Common Applications 


It is IBM’s intent to develop applications that conform to Systems Application Archi- 
tecture, making use of the common user access, the common programming inter- 
face, and the common communications support. These will be key applications 
that satisfy a significant customer need for use across the three Systems Applica- 
tion Architecture environments. Availability of these applications will help cus- 
tomers solve today’s business problems in the most efficient and effective way. 


Benefits 
These IBM-written applications will obtain the same benefits from Systems Appli- 
cation Architecture as those applications written by customers and independent 
software vendors. They will offer consistency in how functions are implemented, 
how panels are laid out, and how the user navigates within the application in all 
the supported environments. Thus, an application initially developed for one envi- 
ronment and subsequently ported to another will appear consistent to the applica- 
tion user. This consistency will also apply to integrated “families” of applications 
which will be offered. 


Users of MFI (Mainframe Interactive) workstations and IWS (Intelligent Work- 
stations) could have a consistent set of defined functions, and where applicable, 
the IWS user may have additional defined functions available for the application or 
family of applications. Hosts controlling the MFI station will provide the user 
access functions. These functions will, within the limits of technology, have a rea- 
sonable consistency with the IWS’s user access. 


Initial Focus 
Initially, the IBM application development effort will focus on integrated office and 
decision support. Later, it will expand into industry-specific applications. 


In the initial focus on office applications, the elements being defined include: 


¢ Document processing 
¢ Document library 

° Personal services, mail 
e Decision support. 


Current Product Base 
Many of IBM’s current office and decision support products already use Document 
Content Architecture (DCA), Document Interchange Architecture (DIA), and SNA 
Distribution Services (SNADS). These key architectures are part of Systems Appli- 
cation Architecture, and will conserve the investments that customers have made 
and offer a transition path to new Systems Application Architecture product offer- 
ings. 
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Continued Support in Other Areas 


While this new emphasis will bring additional value to those interested in generai- 


ized business solutions, the familiar types of support will continue to be provided 
and enhanced. 


e Continuity will be maintained with existing products and systems. This means 
that current investments in applications and knowledge will retain their value. 


e Many other IBM systems and products will be offered outside the Systems 
Application Architecture, ensuring that customers with environment-specific 
business requirements will continue to have those needs satisfied. 


System/370 System/3X Personal Computer 





Figure 4. Both Common and Specialized Solutions Are Offered 
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Future Growth 


In its initial form, Systems Application Architecture and its current IBM product 
implementations offer a starting point. It is IBM’s intent that both definitions and 
implementations increase over time in an evolutionary process. 


General Areas 
Growth is expected to occur in three general ways: 


1. The current specification levels will receive full implementation in all the 
Systems Application Architecture environments. 


. Individual interfaces will grow and become more powerful, incorporating new 
features into the original specifications. 


3. Additional software interfaces and applications will be defined and included 
under the Systems Application Architecture umbrella. 


Thus, consistency will grow, and with it — the value to customers. 





Figure 5. Future Growth 
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National Language Support 
Systems Application Architecture provides IBM with the foundation to enhance the 
availability and consistency of national language implementation in software pro- 
ducts. It is IBM’s intent to develop the Systems Application Architecture specifica- 
tions with support for the implementation of a broad set of national language 
representations. 
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Summary 


Benefits 


Future Growth 


Systems Application Architecture is a definition aimed at helping IBM’s customers 
obtain business solutions. With it, IBM is initiating an evolution in cross-system 
consistency, while continuing to provide its established products and systems. 


Systems Application Architecture is designed to afford growing commonality 
across the System/370 (TSO/E under MVS/XA, and CMS under VM), System/3X, 
and Personal Computer (Operating System/2) in the areas of programming inter- 
faces, user access, communications support, and prebuilt applications, as well as 
national language support. 


For each of these areas, IBM is establishing and will publish specifications — defi- 
nitions of the elements that will be common across the three systems. Future IBM 
Systems Application Architecture products will then implement those specifica- 
tions. 


IBM’s Systems Application Architecture will offer customers several advantages: 
¢ Programming skills that have broader use 
e Applications that can be ported with less effort, or that can span systems 
e User access to these applications that is simpler and more uniform. 


Both development costs and training costs should be reduced. Customers seeking 
broad solutions for their personal, departmental, and enterprise-wide data proc- 
essing needs will! profit. And independent software vendors who choose to build 
on IBM products will benefit as well. 


The initial IBM definitions and product implementation levels provide a starting 
point for cross-system consistency. Over time, both the definition and implementa- 
tion of Systems Application Architecture will expand, and the level of consistency 
will increase. 


Thus, customers will see an evolutionary process — a continual broadening and 
reinforcement of consistency, with an attendant increase in benefits. 
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Part Two: Contents of the Programming Interface 


19 





Part Two: Contents of the Programming Interface 


On the following pages are descriptions of the components of the Common Pro- 
gramming Interface, with accompanying tables. Each table provides: 


¢ A high-level list of the contents of the component — those elements in the IBM 
specification 


¢ An indication of where each element is currently supported — that is, what 
Systems Application Architecture environments already have a released or 
announced licensed program which implements that interface element. 


System/3X Considerations: Although the System/3X computing environment is not 
referenced in the tables, it is IBM’s intent to implement the Common Programming 
Interface in future offerings of the System/3X. It is also IBM’s intent that current 
System/36 and System/38 programming interfaces will continue to be supported on 
future offerings of the System/3X, conserving current application investment. 


Reference Manuals 
The tables here offer a general overview of the contents of the components of the 
interface. Comprehensive reference manuals are being prepared as well. These 
manuals will provide the full contents of each component, and constitute the IBM 
specifications for them. As the interface expands, the manuals will be updated 
accordingly. | 


The IBM Common Programming Interface may be reproduced, used, and distrib- 


uted for the purpose of developing application programs in accordance with the 
terms accompanying the copyright statement in the reference manuals. 
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Languages 


Application Generator 22 
C 26 
COBOL 31 
FORTRAN 38 
Procedures Language 40 
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Application Generator 
An application generator is a generalized application development tool. It allows 
one to build some types of programs easily without using a traditional high-level 
language or being involved with system details. Application generators can be cat- 
egorized as fourth-generation tools for the professional programmer. 


Seated at the terminal, a programmer can create an application interactively. An 
application generator offers: 


e A dialog-oriented, fill-in-the-blanks approach 
e Immediate interactive syntax checking 


e Prompting, tutorials, and a help facility. 


Use of an application generator eliminates many of the steps required when cre- 
ating applications using conventional methods. Each phase of certain projects — 
defining and validating screens, files, and logic; testing and debugging programs; 
and running trial executions of the application — can be completed under its guid- 
ance. Through each of these steps, it buffers the user from the complexities of 
system and data management. 


IBM’s application generator interface is tailor-made for supporting portability 
across systems. Its two-part structure — an application development portion (AD) 
and an application execution portion (AE) — allows an application to be built on 
one system and easily run on another (where the AE functions are installed). The 
AD function generates an application that is relatively independent of operating 
system and hardware considerations. When the application is actually used, AE 
handles the implementation and automatically adapts the code to the specific 
system it is running on. 


The Interface for Systems Application Architecture 
The interface specification is based on the existing System/370 Cross System 
Product/Application Execution. Thus, current product users will find the contents of 
the new interface to be familiar. For more information, see the table on the fol- 
lowing pages. 
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Languages — Application Generator 


The table below lists the elements currently in the application generator interface 


for Systems Application Architecture. 


The table indicates (with an X) which systems already have an IBM licensed 
program announced or available that implements a particular language element. 


On MVS and VM, the implementing product is Cross System Product/Application 


Execution, Version 3 (5668-814). An asterisk (*) indicates interface elements avail- 


able in EZ-RUN Cross System Product/Application Execution (6317011 feature 
number 9375) running in PC DOS compatibility mode of Operating System/2. 


Interface Element OS/2 


Processing Statements 

Arithmetic operators 

Conditional operators 

MOVE data item content 

MOVE corresponding at structure level 

Logic controls (IF, ELSE, AND, OR, WHILE) 

FIND in a table 

RETRIEVE from table 

SET record status 

SET map status 

SET map item attribute 

TEST map, map or data item, record, or 
entry key 

CALL application 

TRANSFER to an application 

PERFORM a process 

Go to a process 

Statement group subroutines 
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Process Options 
EXECUTE statements 

DISPLAY a map 

CONVERSE a map 

ADD a record into a file 

DELETE a record from a file 

Read a record (INQUIRY) 

Read record for update (UPDATE) 
REPLACE a record 
SCAN for next record 
CLOSE a file or printer 
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Figure 6 (Part 1 of 3). Major Elements of the Application Generator Interface 
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Languages — Application Generator 


Interface Element OS/2 


Special Functions 

Transfer application name variable 

Gregorian date 

Julian date 

Time 

Exit from an application 

Exit from statement group 

Go To application flow logic 

Entry key !D (AID) 

MSG ID to be displayed 

Map message field 

User ID 

Control hard I/O errors 

Control arithmetic overflows 

Test overflow results 

Data base commitment control 

Table FIND result (row number or array 
index) 


KK KK KK KK KK OK OK OK OK OK OK 
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File and Data Base 

Indexed access 

Relative access 

Serial access 

Working storage definition 
Redefined records 

Key item name 

Alternate record specification 


Record Data Items 
ltem name 

Structures 

Arrays 

Binary data 

Character data 
Hexadecimal data 
Unsigned numeric data 
Signed numeric data 
Packed numeric data 
Unsigned packed numeric data 
Decimal positions 
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Figure 6 (Part 2 of 3). Major Elements of the Application Generator Interface 
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Languages — Application Generator 


Interface Element mvs | VM OS/2 


Reference and Edit Tables 
Reference table 

Match valid edit table (include) 
Match invalid edit table (exclude) 
Range match valid edit table 
Column definition 

Contents definition 





Screen and Printer Maps 

Map group name 

Map name (within a group) 
Map size for partial maps 
Partial map position 

Initial cursor position 

Fold character input option 
Help map name 

Help PF key 

Map formats 

Map variable field name 

Map field arrays 

Field attribute definition 
Display device selection 

Map variable editing sequence 
Map variable output editing 
Map variable input editing and validation 


Km KK KK KK KK KK OK KK OK OK 
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Application 

Name 

Type (main or called, transaction or batch) 
Default help PF key 

Process I/O option 

Process object name 

Process |/O error routine 

Logic flow 

Table and additional records list 

Called parameter list 


xxxx*x «xx 
xxx ***K*K RX 


Figure 6 (Part 3 of 3). Major Elements of the Application Generator Interface 
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C is a programming language designed for a wide variety of programming tasks. It 
has been used for system-level code, text processing, graphics, and for develop- 
ment of engineering, scientific, and commercial applications. 


The C language itself is compact, with function added through its library. This divi- 
sion has resulted in C being regarded as both flexible and efficient. An additional 
benefit is that the language is highly consistent across different systems. 


C’s flexibility permits its users to deal easily with machine-level entities at a low 
level, while at the same time having the high-level control and data structures 
found in other modern, structured programming languages. 


Included is an extensive library of functions to provide input and output, math- 
ematics, exception handling, string and character manipulation, dynamic memory 
management, as well as date and time manipulation. Use of this library helps to 
maintain program portability, because the underlying implementation details for 
the various operations need not be of concern to the programmer. 


C supports numerous data types, including characters, integers, floating-point 
numbers and pointers — each in a variety of forms. In addition, C also supports 
data aggregates such as arrays, structures (records), unions, and enumerations. 


The Interface for Systems Application Architecture 
The interface specification has been developed in accord with the draft proposed 
American National Standard Programming Language - C (X3J11). For more infor- 
mation on the IBM specification, see the table on the following pages. 
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Languages — C 


The table below lists the language elements currently in the C interface for 
Systems Application Architecture. | 


The table indicates (with an X) which systems already have an IBM licensed 
program announced or available that implements a particular language element. 
On Operating System/2 (Personal Computer), the implementing product will be IBM 
C/2. 


An asterisk (*) indicates language elements that are consistent with the C Program 
Offerings for MVS and VM (5713-AAG and 5713-AAH). Although not part of Systems 
Application Architecture, these program offerings can be used to gain early experi- 
ence with the C interface. 


Language Element OS/2 


Data Types 

signed keyword 
volatile keyword 
const keyword 

void * pointers 
enumerated datatype 
long double datatype 


Language Features 

Adjacent strings concatenated 
Full function prototypes 
Ref-Def model for externs 


Preprocessor Directives 
if/ifdef/ifndef 
else/elif/endif 
define 
line 
include 
pragma 
undef 
Escape sequences 
\a \b \f \n \r \t \v 
\ooo — octal 
\xhhh — hexadecimal 
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Predefined Macros 
__LINE _ macro 
__FILE__ macro 





Figure 7 (Part 1 of 4). Major Elements of the C Interface 
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Languages — C 


Language Element mvs | VM OS/2 


Standard I/O: 
Standard streams 
stdin/stdout/stderr 
File operations 
remove 
rename 
tmpfile/tmpnam 
File access 
fclose 
fflush 
fopen 
freopen 
setbuf/setvbuf 





Formatted I/O 
printf/fprintf/sprintf 
vprintf/vfprintf/vsprintf 
scanf/fscanf/sscanf 

Character I/O 
fgetc/getc/getchar 
fputc/putc/putchar 
fgets/gets 
fputs/puts 
ungetc 

Direct I/O 
fread/fwrite 
ftell/fseek 
rewind 

Error-handling 
clearerr 
feof 
ferror 


Figure 7 (Part 2 of 4). Major Elements of the C interface 
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Languages — C 


Language Element |Mvs | VM OS/2 


Signal Handling: 
signal function 
Signals Supported: 
SIGABRT 
SIGFPE 
SIGILL 
SIGINT 
SIGSEGV 
SIGTERM 
SIGUSR1 
SIGUSR2 





x 
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Non-Local Jumps: 
setimp/longjmp 


Mathematical: 
cos/sin/tan 
acos/asin/atan/atan2 
exp/log/log10 
frexp/Idexp 
modf/fmod 

pow/sart 
ceil/floor/fabs 

Bessel functions 
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General Utilities: 

String conversion 
atof/atoi/atol 
strtod/strtol 

Pseudo-random numbers 
rand/srand 

Memory management 
calioc/malloc/realloc 
free 

Environment interactions 
abort 
exit 
getenv 
system 

Searching and sorting 
bsearch/qsort 

Integer arithmetic 
abs/labs 


Figure 7 (Part 3 of 4). Major Elements of the C Interface 
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Languages — C 


Language Element /MVS | VM OS/2 


Variable Arguments: | , 
va_Start/va_arg/va_end 
vprintf/vfprintf/vsprintf . 
String Operations: 
strlen 
strstr 
strtok 
strpbrk 
strcat/strncat 
strcmp/strncmp 
strcpy/strncpy 
sirchr/strrchr 
strspn/strcspn 
Memory Block Operations: 
memcpy, memcmp 
memchr, memset 
Date and Time: 
Time manipulation 
difftime 
time 
Time conversion 
asctime 
ctime 
gmtime 
localtime 
Character Handling: 
Character testing 
isalnum/isalpha/iscntrl | 
isdigit/isgraph/islower 
isprint/ispunct/isspace 
isupper/isxdigit 
Character case mapping 
tolower/toupper 


Figure 7 (Part 4 of 4). Major Elements of the C Interface 
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COBOL 


COBOL is a widely-used application programming language. Its success is due 
largely to: 


e lts power in handling the data processing needs of business 


¢ The natural English-like appearance of the language, which makes it easy to 
write and maintain applications. 


Programs written in COBOL are geared to handle large volumes of data from 
‘sources as different as magnetic tapes and display terminals. After manipulating 
this data, the programs can produce a variety of outputs, such as printed reports or 
files on disk storage devices. COBOL is also flexible enough to handle a wide 
range of data processing needs — from the overnight processing of a company 
payroll to the “Il-need-an-answer-now” demands of insurance claim inquiries. 


The Interface for Systems Application Architecture 


in general, the language elements in the IBM specification fall into three catego- 
ries: 


e American National Standard Programming Language - COBOL, ANSI 
X3.23-1985, ISO standard 1989-1985, Intermediate Level 


¢ Some elements from ANSI X3.23-1985, High Level 
e IBM enhancements to this standard — such as COMP-3 and COMP-4 data 


items. 
Because the IBM specification is based largely on these well-known and accepted 
industry standards, programmers will find several benefits: 
¢ Familiarity 
¢ Ability to use existing standard programs currently running on IBM systems 
¢ Ability to take standard programs from non-IBM systems and run them on the 


supported architectures. 


For enhanced programmer productivity and ease of use, IBM’s specification will 
contain other language features beyond the industry standards. For more informa- 
tion, see the table on the following page. 
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Languages — COBOL 


The table below lists the language elements currently in the COBOL interface for 
Systems Application Architecture. This specification is based largely on the 1985 

ANS COBOL standard, at the Intermediate Level. (Language elements that are 
new in the 1985 standard are printed in italics.) To this standard, IBM also adds 
certain extensions. 


The table indicates (with an X) which systems already have an IBM licensed 
program announced or available that implements a particular language element. 


On MVS and VM, the VS COBOL II product (5668-958) provides the COBOL inter- 
face, with the exception of certain 1985 ANS COBOL Intermediate Level items. On 
Operating System/2 (Personal Computer), the implementing product will be IBM 
COBOL/2. 


[ange Elmont ——SSS~*sd NS vos 


ANS LANGUAGE ELEMENTS 
NUCLEUS MODULE 


Language Concepts: 
COBOL words 
Characters a-z in COBOL words 
Literals 
PICTURE character-strings 
Comment-entries 
Qualification 
50 levels of qualifiers 
Subscripting (data-name/literal) 
Mixed indexes and subscripts 
Relative subscripting 
Subscripting (index-name) 


X 
X 
X 
X 
X 
X 
X 
X 
X 
X 
X 


Reference format: 
TITLE 

Sequence number 
Comment lines 
Debugging lines 


IDENTIFICATION DIVISION: 
PROGRAM-ID paragraph 
AUTHOR paragraph 





Figure 8 (Part 1 of 6). Major Elements of the COBOL Interface 
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Languages — COBOL 


Language Element sMvs jvm | OS/2 


INSTALLATION paragraph 
DATE-WRITTEN paragraph 
DATE-COMPILED paragraph 
SECURITY paragraph 





ENVIRONMENT DIVISION: 
Configuration Section: 
SOURCE-COMPUTER paragraph 
OBJECT-COMPUTER paragraph 
SPECIAL-NAMES paragraph 
Aiphabet-name clause: 

word ALPHABET 

STANDARD-2 option (ISO 7-Bit Code) 

CLASS clause 


Input-Output Section: 
File control entry: 
ASSIGN TO literal 


DATA DIVISION: 
Working-Storage Section: 
BLANK WHEN ZERO clause 
Data-name or FILLER clause 
JUSTIFIED clause 
Level-number 
OCCURS clause 

VALUE clause allowed with OCCURS 
PICTURE clause 
REDEFINES clause 
RENAMES clause 
SIGN clause 
SYNCHRONIZED clause 
USAGE clause 

BINARY 

PACKED-DECIMAL 
VALUE clause 
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PROCEDURE DIVISION: 
Arithmetic expressions 
Conditional expressions 
Relation condition: 
Relational operators: 
GREATER THAN OR EQUAL TO 
> 


Figure 8 (Part 2 of 6). Major Elements of the COBOL Interface 
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Languages — COBOL 


Language Element OS/2 


LESS THAN OR EQUAL TO 
a 
Class condition: 
ALPHABETIC (uppercase and lowercase 
alphabetic characters) 
ALPHABETIC-LOWER 
ALPHABETIC-UPPER 
class-name 
ACCEPT statement 
ADD statement 
TO identifier/literal GIVING identifier 
NOT ON SIZE ERROR phrase 
END-ADD phrase 
ALTER statement 
COMPUTE statement 
NOT ON SIZE ERROR phrase 
END-COMPUTE phrase 
CONTINUE statement 
DISPLAY statement 
DIVIDE statement 
NOT ON SIZE ERROR phrase 
END-DIVIDE phrase 
ENTER statement 
EXIT statement 
EVALUATE statement 
GO TO statement 
IF statement 
END-IF phrase 
INITIALIZE statement 
INSPECT statement 
CONVERTING phrase 
MOVE statement 
MULTIPLY statement 
NOT ON SIZE ERROR phrase 
END-MULTIPLY phrase 
PERFORM statement 
In-line Perform 
END-PERFORM phrase 
UNTIL phrase 
WITH TEST BEFORE/AFTER phrase 
VARYING phrase 
WITH TEST BEFORE/AFTER phrase 
SEARCH statement 
END-SEARCH phrase 
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Figure 8 (Part 3 of 6). Major Elements of the COBOL Interface 
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Languages — COBOL 


Language Element Laie OS/2 


SEARCH ALL statement 
END-SEARCH phrase 
SET statement 
Mnemonic-name TO ON/OFF 
Condition-name TO TRUE 
STOP statement 
STRING statement 
NOT ON OVERFLOW phrase 
END-STRING phrase 
SUBTRACT statement 
NOT ON SIZE ERROR phrase 
END-SUBTRACT phrase 
UNSTRING statement 
NOT ON OVERFLOW phrase 
END-UNSTRING phrase 
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l-O MODULES 


ENVIRONMENT DIVISION: 
Input-Output Section: 
File control entry: 
SELECT clause 
ASSIGN clause 
ASSIGN TO literal 
“ORGANIZATION clause 
ACCESS MODE clause 
RECORD KEY clause 
ALTERNATE RECORD KEY clause 
FILE STATUS clause 
RESERVE AREA clause 
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| |-O-CONTROL paragraph: 
RERUN clause 
SAME clause 
MULTIPLE FILE TAPE clause 


DATA DIVISION: 

File Section: 

FD file name 
BLOCK CONTAINS clause 
CODE-SET clause 
DATA RECORDS clause 
LABEL RECORDS clause 
LINAGE clause 
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Figure 8 (Part 4 of 6). Major Elements of the COBOL Interface 
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Languages — COBOL 


Language Element wee OS/2 


RECORD clause 
VALUE OF clause 
Record description entry 












PROCEDURE DIVISION: 
CLOSE statement 
DELETE statement 
NOT INVALID KEY phrase 
END-DELETE phrase 
OPEN statement 
READ statement 
NOT AT END phrase 
NOT INVALID KEY phrase 
END-READ phrase 
REWRITE statement 
NOT INVALID KEY phrase 
END-REWRITE phrase 
START statement 
NOT INVALID KEY phrase 
END-START phrase 
USE statement 
WRITE statement 
NOT AT END-OF-PAGE (EOP) phrase 
NOT INVALID KEY phrase 
END-WRITE phrase 
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File Status Codes 
New File Status Codes 
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INTER-PROGRAM COMMUNICATION MODULE 









LINKAGE SECTION 







PROCEDURE DIVISION: 
PROCEDURE DIVISION USING 
CALL statement 
ON EXCEPTION phrase 
NOT ON EXCEPTION phrase 
END-CALL phrase 
CANCEL statement 
EXIT PROGRAM statement 
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Figure 8 (Part 5 of 6). Major Elements of the COBOL Interface 
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Languages — COBOL 


Language Element MVS [VM | OS/2 


SORT-MERGE MODULE 


ENVIRONMENT DIVISION: 
Input-Output Section: 
FILE-CONTROL paragraph 
File control entry 

SELECT clause 

ASSIGN clause 

ASSIGN TO literal 
SAME clause 


DATA DIVISION: 

File Section: 

SD Sort-Merge File 
Record description entry 
DATA RECORDS clause 
RECORD clause 


PROCEDURE DIVISION: 
MERGE statement 
RELEASE statement 
RETURN statement 
NOT AT END phrase 
END-RETURN phrase 
SORT statement 
DUPLICATES phrase 


SOURCE TEXT MANIPULATION MODULE 
COPY statement xX 


IBM EXTENSIONS 


Special Register WHEN-COMPILED 

ID DIVISION abbreviation 

Optional IDENTIFICATION DIVISION para- 
graphs in any order 

Second file status 

USAGE COMPUTATIONAL-3 (COMP-3) 
USAGE COMPUTATIONAL-4 (COMP-4) 
ACCEPT FROM CONSOLE/SYSIN 
DISPLAY UPON CONSOLE/SYSOUT 
GOBACK statement 

EJECT and SKIP1/2/3 statements 
TITLE statement 


x x< X< 
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Figure 8 (Part 6 of 6). Major Elements of the COBOL Interface 
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FORTRAN 


FORTRAN is a programming language designed for jobs involving mathematical 
computations and other manipulation of numeric data. This makes it especially 
well-suited to scientific and engineering applications. 


Because it is simple and easy to learn, and because it produces efficient code, 
FORTRAN is widely used. It forms a convenient and familiar tool for anyone 
involved in mathematical computation. Scientists, engineers, and students are 
only a few of the many people who use it. 


The original FORTRAN was developed by IBM. Over the years, IBM has continued 
to enhance the language and to offer more powerful and sophisticated FORTRAN 
products with a variety of features on all its systems. 


The Interface for Systems Application Architecture 


The interface specification provides a language that has the familiar simplicity of 
its predecessors, but also incorporates new features. In general, the language ele- 
ments fall into two categories: 


¢ American National Standard Programming Language - FORTRAN, ANSI 
X3.9-1978 (FORTRAN 77), ISO standard, 1539-1980. 


e Enhancements to this standard — such as the ability to use names that are up 
to 31 characters long. 
Because the IBM specification is based on the ANS standard, users will obtain 
several benefits: 
e Familiarity 


e Ability to use existing programs currently running on IBM systems (many of 
which are based on the ANS 77 standard) 


e Ability to take standard programs from non-IBM systems and run them on the 
supported IBM architectures. 


For enhanced programmer productivity and ease of use, IBM’s specification will 
contain language features beyond the industry standards. For more details, see 
the table on the following page. 
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Languages — FORTRAN 


The table below lists the language elements currently in the FORTRAN interface for 
Systems Application Architecture. 


The table indicates (with an X) which systems already have an IBM licensed 
program announced or available that implements a particular language element. 


On MVS and VM, the VS FORTRAN Version 2 product (5668-806) provides the 
FORTRAN interface, with the exception of the INCLUDE statement. On Operating 
System/2 (Personal Computer), the implementing product will be IBM FORTRAN/2. 


Language Element 


1977 ANS FORTRAN — all elements 
INTEGER*2 

LOGICAL*1 

COMPLEX"*16 

COMPLEX"16 intrinsic functions 
ISA S61.1 bit routines 

IMPLICIT NONE 

INCLUDE 

31-character names 

Mixed case names 

IBM minimum compiler limits 


xX KKK KK KK KK KO 
. 





Figure 9. Major Elements of the FORTRAN Interface 


Part Two: Contents of the Programming Interface 39 


Procedures Language 
IBM’s procedures language allows one to write programs in a clear, structured 
way. In its REXX implementation, it has proved to be easy to learn and teach. The 
clarity it offers makes it useful to professional programmers and “casual” users 
alike. Powerful character and arithmetic abilities make it suited for programs large 
orsmall. Its conventional syntax provides a flexible language suited for use not 
only as a command and macro language, but as a full-function development lan- 
guage as well. 


Ease of use is a distinctive feature of the procedures language. Furthermore, its 
design allows dynamic interpretation of statements, if desired. 


The procedures language’s other features include: 


Presentation of host commands to the system 
External and internal calling mechanisms 
Structured programming constructs, such as IF-THEN-ELSE and SELECT 


Expressions, including arithmetic, concatenation, comparative, and logical 
operators — all of which act upon variables that can contain either character 
strings or numbers 


Extensive string parsing by pattern matching; a string (possibly the input from 
an external source) can be split into parts and assigned to variables as needed 


Exception handling and tracing mechanisms. 


The interface for Systems Application Architecture 
The interface specification is based largely on the REXX language currently avail- 
able as part of the VM operating system. For more information on the contents of 
this specification, see the table on the following pages. 
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Languages — Procedures Language 


The table below lists the language elements currently in the procedures interface 
for Systems Application Architecture. 


The table indicates (with an ”X”) which systems already have an IBM component 
announced or available that implements a particular language element. 


The current implementation in the CMS component of VM/SP is the System Product 
Interpreter (also known as REXX). 


Language Element 


General Concepts 
Assignment statement 
Null clause 

Labels 

Commands 

Simple variables 
Compound variables 
Constant symbols 
Literal strings 
Hexadecimal literal strings 
Internal function calls 
External function calls 
Integer numbers 
Decimal numbers 
Exponential notation 
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Instructions 
ADDRESS instruction 
ARG instruction 
CALL instruction 
simple DO 
repetitive DO 
DO FOREVER 
DO WHILE 
DO UNTIL 
controlled repetitive DO 
DROP 

| EXIT 
IF-THEN-ELSE 
INTERPRET 
ITERATE 
LEAVE 
NOP 
NUMERIC DIGITS 
NUMERIC FORM 
NUMERIC FUZZ 
OPTIONS 
PARSE ARG 
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Figure 10 (Part 1 of 4). Major Elements of the Procedures Language 
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Languages — Procedures Language 


Language Element Mvs jvm | OS/2 


PARSE PULL 
PARSE SOURCE 
PARSE VALUE 
PARSE VAR 
PARSE VERSION 
PROCEDURE 
PROCEDURE EXPOSE 
PULL 

PUSH 

QUEUE 

RETURN 

SAY 

SELECT 

SIGNAL 

SIGNAL ON 
TRACE 
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Functions 

ABBREV built-in function 
ABS built-in function 
ADDRESS built-in function 
ARG built-in function 
BITAND built-in function 
BITOR built-in function 
BITXOR built-in function 
CENTRE built-in function 
CENTER built-in function 
COMPARE built-in function 
COPIES built-in function 
C2D built-in function 

C2X built-in function 
DATATYPE built-in function 
DATE built-in function 
DELSTR built-in function 
DELWORD built-in function 
D2C built-in function 

D2X built-in function 
ERRORTEXT built-in function 
FORMAT built-in function 
INSERT built-in function 
LASTPOS built-in function 
LEFT built-in function 
LENGTH built-in function 
MAX built-in function 

MIN built-in function 
OVERLAY built-in function 
POS built-in function 


X 
X 
X 
X 
X 
X 
X 
X 
X 
X 
X 
X 
X 
X 
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X 
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X 
X 
X 
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Figure 10 (Part 2 of 4). Major Elements of the Procedures Language 
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Language Element 


QUEUED built-in function 
RANDOM built-in function 
REVERSE built-in function 
RIGHT built-in function 

SIGN built-in function 
SOURCELINE built-in function 
SPACE built-in function 
STRIP built-in function 
SUBSTR built-in function 
SUBWORD built-in function 
SYMBOL built-in function 
TIME built-in function 
TRACE built-in function 
TRANSLATE built-in function 
TRUNC built-in function 
VALUE built-in function 
VERIFY built-in function 
WORD built-in function 
WORDINDEX built-in function 
WORDLENGTH built-in function 
WORDS built-in function 
XRANGE built-in function 
X2C built-in function 

X2D built-in function 


Operators 

= comparative operator 
— = comparative operator 
> comparative operator 
< comparative operator 
< > comparative operator 
> < comparative operator 
> = comparative operator 
— < comparative operator 
<= comparative operator 
— > comparative operator 
= = comparative operator 
— = = comparative operator 
& boolean operator 

| boolean operator 

&& boolean operator 
Prefix — boolean operator 
(blank) concatenation 

|| concatenation 

(abuttal) concatenation 

+ arithmetic operator 

- arithmetic operator 





Languages — Procedures Language 
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Figure 10 (Part3 of 4). Major Elements of the Procedures Language 
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Languages — Procedures Language 


= 
< 
7) 
< 
= 


Language Element 





* arithmetic operator 

/ arithmetic operator 

% arithmetic operator 

// arithmetic operator 

** arithmetic operator 

Prefix - arithmetic operator 

Prefix + arithmetic operator 
Parentheses and operator precedence 
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Parsing 

Word parsing 

Literal parsing triggers 
Variable parsing triggers 
Absolute column parsing 
Relative column parsing 


Special Features 

RC special variable 

RESULT special variable 

SIGL special variable 

Variable pool interface (EXECCOMM in CMS) 


Figure 10 (Part 4 of 4). Major Elements of the Procedures Language 
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Services 


Database Interface 46 
Dialog Interface 50 
Presentation Interface 52 
Query Interface 58 
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Database Interface 
Access to data bases is provided through SQL (Structured Query Language). It 
allows users to define, retrieve, and manipulate information in a relational data 
base. 


SQL is nonprocedural. Users specify what they want to do, and don’t need to be 
concerned with how it’s done. Syntax Is straightforward and easy for even occa- 
sional users to learn and remember. Simple yet powerful, single statements can 
perform the same function as many lines of conventional code. SQL makes 
complex operations possible and typical tasks easy. 


SQL also provides built-in functions and arithmetic operations, so programmers 
can perform immediate mathematical operations on data, often without having to 
write traditional programs. On the other hand, if noninteractive processing is 
desired, SQL statements can be imbedded in traditional application programs, 
written in such languages as COBOL or FORTRAN, and then precompiled. 


SQL is based on the relational data model, an advanced technology that makes 
data easier to access and use. Various pieces of information can be viewed in 
relationship to each other without predefining that relationship in the data base 
structure. This easier, more flexible method allows users and applications to 
share and access data in an ad hoc fashion to support changing requirements for 
information. 


The description of how data is stored or managed is nota part of the application. 
Therefore, storage and management of data can be optimized to each environment 
without impacting the portability of the application or the application development 
process. 


The Interface for Systems Application Architecture 
The specification for the SQL language provides a framework for similar data 
access in the supported architectures. This means that an application can be 
moved from environment to environment with minimal change. 


IBM’s specification has been developed with consideration for the American 
National Standard Database Language - SQL, ANSI X3.135-1986. The IBM specifi- 
cation is almost identical to the language in DB2 and SQL/DS, so current users of 
those System/370 licensed programs will have the benefits of familiarity. For more 
specifics, see the table on the following page. 
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Services — Database Interface 


The table below lists the language elements currently in the database interface for 
Systems Application Architecture. 


The table indicates (with an X) which systems already have an IBM licensed 
program announced or available that implements a particular language element. 


On MVS, the implementing product will be DB2 Release 3 (5740-XYR). On VM, it 
will be SQL/DS Version 2 (5688-004). On the Personal Computer, the implementa- 
tion will be provided by the IBM Operating System/2 Database Manager. 


[Language Emons ——SSSS~=idi NS [os 


SELECT Expressions 
SELECT list 

FROM clause 
WHERE clause 
GROUP BY clause 
HAVING clause 





Data Definition 
CREATE TABLE 
CREATE VIEW 
ALTER TABLE 
CREATE INDEX 
DROP INDEX 
DROP TABLE 
DROP VIEW 
COMMENT ON 


Kx KK KK KK OK 
KK KK KKK XK 
Kx KK KK KK OK 


Authorization 
GRANT 
REVOKE 


Basic Statements 
INSERT 

SELECT 

UPDATE ... WHERE 
DELETE ... WHERE 


Figure 11 (Part 1 of 3). Major Elements of the Database Interface 
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Services — Database interface 


Language Elements mvs | VM OS/2 


Cursor-Oriented Operations 
DECLARE CURSOR 

ORDER BY 

SELECT ... FOR UPDATE 
UNION 

OPEN 

FETCH 

DELETE 

UPDATE 

CLOSE 


x KKK KK OK OK OK 
x KKK KK OK OK OX 


Dynamic Facilities 
PREPARE 

DESCRIBE 

EXECUTE 

EXECUTE IMMEDIATE 
SQLDA 


Miscellaneous Statements 
INCLUDE 

LOCK TABLE 

WHENEVER 


Data Types 
CHARACTER 
VARCHAR 
LONG VARCHAR 
INTEGER 
SMALLINT 
DECIMAL 
FLOAT 

DATE 

TIME 
TIMESTAMP 


Kx KK KK KK OK OK OK 
KKK KK KK KK XK 
KKK KK KK OK OK OX 





Figure 11 (Part 2 of 3). Major Elements of the Database Interface 
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Services — Database Interface 


Language Elements mvs | VM OS/2 


Other Language Elements 
Nuli Values 

Host Variable References 
Indicator Variables 
Column References 
Ordinary Identifiers 
Delimited Identifiers 
Functions: AVG, MIN, MAX, SUM, COUNT 
Arithmetic Operators 
Comparison Operators 
BETWEEN Predicate 

IN Predicate 

LIKE Predicate 

IS NULL Predicate 
ALL/ANY Predicate 
EXISTS Predicate 

Search Condition 

SQLCA 


KKK KK KK KKK KK KK KK OK 
KKK KK KK KK KK KK KK KK 
KKK KKK KK KKK KK KK KK 


Pre-Compilers 
C 

COBOL 
FORTRAN 





Figure 11 (Part 3 of 3). Major Elements of the Database Interface 
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Dialog Interface 


Dialog services help programmers develop interactive applications. These ser- 
vices fall into two broad categories: 


¢ The control of the display and interaction of panels containing constant and 
variable information on a screen, including: 


— menu selections 
— help information 
— data requests 

— messages 


e The passing to the application of data and function requests from the user. 


Thus, assistance is provided when a user is choosing general functions available 
in the whole system, or when data (input and responses) is being moved between a 
user and a specific application. 


From the application developer’s point of view, this management function can be 
thought of as a convenient, easy-to-use extension of the operating system’s ser- 
vices. It helps the application developer code functions such as input field vali- 
dation, message services, and help facilities. 


Along with presentation, consistent dialog management buffers the programmer, 
the application, and the user from device-dependent considerations. This 
enhances application portability and simplifies application development. The pro- 
grammer will use similar development tools across operating environments, 
gaining in productivity. And the users of these applications will have a consistent 
view across applications and systems. 


The Interface for Systems Application Architecture 


The interface specification for dialog is based on the existing Personal Computer 
EZ-VU Run Time Facility. Thus, current product users will find the new interface 
familiar. For more information, see the table on the following page. 


50 Systems Application Architecture: Overview 


Services — Dialog Interface 


The table below lists the elements currently in the dialog interface for Systems 
Application Architecture. 


The table indicates (with an X) which systems already have an IBM licensed 
program announced or available that implements a particular element. 


On the Personal Computer, the implementation will be provided by the IBM Oper- 
ating System/2 Dialog Manager. 
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|; Panel Services 
CONTROL (changes panel characteristics) 
DMSELECT (selects another menu panel) 
PANDEL (deletes a panel) 
PANDISP (displays a panel) 
PANREAD (gets input from a panel) 
PANWRITE (writes a panel) 
SETCUR (positions cursor) 
SETMSG (writes a message) 
Variable Services 
VDEFARR (defines an array) 
VDEFINE (defines a scalar) 
VDELETE (deletes a variable) 
VGET (gets a variable) 
VOBTAIN (gets a variable) 
VPUT (puts a variable) 
VRESET (deletes a pool) 
VUPDATE (puts a variable) 
Supported Languages 
C support 
COBOL support 
FORTRAN support 


Figure 12. Major Elements of the Dialog Interface 


X 
X 
X 
X 
X 
X 
X 
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Presentation Interface 
Presentation services provide programmers and users with a comprehensive Set of 
functions that allow information to be displayed or printed in the most effective 
manner. 


The major functions provided are: 


¢ A windowing system that the user can tailor to display selected information 
from one or several applications 


e Support for presentation and interaction via the keyboard and mouse to enable 
applications to conform to the Common User Access 


¢ Comprehensive graphics support 
e Limited image support 
e Saving and restoring graphics pictures 


e Support for many types of display terminals, printers, and plotters. 


By their very nature, presentation services buffer the programmer, the application, 
and the user from device-dependent considerations, thus enhancing application 
portability and simplifying application development. A cross-system specification 
augments these inherent benefits. 


The Interface for Systems Application Architecture 
The interface specification is based largely on the existing System/370 GDDM 
(Graphical Data Display Manager). Thus, the new specification will be familiar to 
current GDDM users. 


For more information on the contents of the specification, see the table on the fol- 
lowing pages. 
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Services — Presentation Interface 


The table below lists the calls currently in the presentation interface for Systems 
Application Architecture. 


The table indicates (with an X) which systems already have an IBM licensed 
program announced or available that implements a particular call. 


On MVS and VM, the GDDM/MVS and GDDM/VM products (5665-356 and 5664-200, 
respectively) provide the presentation interface, with the exception of certain ele- 
ments (primarily in the area of windows). On the Personal Computer, the imple- 

mentation will be provided by the IBM Operating System/2 Presentation Manager. 
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Graphics: 

Floating-point: GSCP, 
GpsSetCurrentPosition, ... 

Fixed-point: GICP, 
GpiSetCurrentPosition, ... 

Line functions: 
GS/GICP Gps/GpiSetCurrentPosition 
GS/GIFLW Gps/GpiSetFracLineWidth 
GS/GILINE Gps/GpiLine 
GSLT GpiSetLineType 
GSLW GpiSetLineWidth 
GS/GIMOVE Gps/GpiMove 
GS/GIPLNE Gps/GpiPolyLine 
GS/GIQCP Gps/GpiQueryCurrentPosition 
GSQFLW GpiQueryFracLineWidth 
GSQLT GpiQueryLineType 
GSQLW GpiQueryLineWidth 


X X 
X X 
X X 
X X 
X X 
X X 
X X 
X X 
X X 
X X 
X X 


KK KK mK KK OK OK OK OK 


Arc functions: 
GSARC GpiCircArc 
GSELPS GpiEllipArc 
GS/GIPFLT Gps/GpiPolyFillet 


Area functions: 
GSAREA GpiBeginArea 
GSENDA GpiEndArea 
GSPAT GpiSetPattern 
GSQPAT GpiQueryPattern 


Color and mix functions: 
GSBMIX GpiSetBackMix 
GSCOL GpiSetColor 
GSMIX GpiSetMix 
GSQBMX GpiQueryBackMix 





Figure 13 (Part 1 of 5). Major Elements of the Presentation Interface 
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Services — Presentation Interface 
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GSQCOL GpiQueryColor 
GSQMIX GpiQueryMix 

















Character functions: 
GS/GICA Gps/GpiSetCharAngle 
GS/GICB Gps/GpiSetCharBox 
GS/GICBS Gps/GpiSetCharSpacing 
GSCD GpiSetCharDirection 
GS/GICH Gps/GpiSetCharShear 
GSCHAP GpiCharString 
(at current position) 

GS/GICHAR Gps/GpiCharStringAt 
(specified position) 

GSCM GpiSetCharMode 

GSCS GpiSetCharSet 

GSTA GpiSetTextAlignment 
GS/GIQCA Gps/GpiQueryCharAngle 
GS/GIQCB Gps/GpiQueryCharBox 
GS/GIQCBS Gps/GpiQueryCharSpacing 
GSQCD GpiQueryCharDirection 
GS/GIQCH Gps/GpiQueryCharShear 
GSQCM GpiQueryCharMode 
GSQCS GpiQueryCharSet 

GSQTA GpiQueryTextAlignment 
GS/GIQTB Gps/GpiQueryTextBox 















x KK KK OK 
x KK KK OK 
Kx KK KK OK 
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Symbol set functions: 
GSDSS GpiLoadSymbolSet 
GSRSS GpiDeleteSymbolSet 
GSQNSS GpiQueryNumberSymbolSets 
GSQSS GpiQuerySymboiSets 
GSQSSD GpiQuerySymbolSetData 
Marker functions: 
GS/GIMARK Gps/GpiMarker 
GS/GIMB Gps/GpiSetMarkerBox 
GS/GIMRKS Gps/GpiPolyMarker 
GSMS GpiSetMarker 
GS/GIQMB Gps/GpiQueryMarkerBox 
GSQMS GpiQueryMarkerSymbol 





Image function: 
GSIMG Gpilmage 

Transform functions: 

GS/GICALL Gps/GpiCallSegment 


Figure 13 (Part 2 of 5). Major Elements of the Presentation Interface 
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Services — Presentation Interface 


Language Element CIEE OS/2 


GS/GISCT Gps/GpiSetModelTransform 
GS/GISORG Gps/GpiSetSegmentOrigin 
GS/GISTFM Gps/GpiSetSegment 
TransformMatrix 

GS/GISAGA Gps/GpiSetSegmentTransform 
GS/GISVL Gps/GpiSetViewingLimits 
GS/GIUWIN Gps/GpiSetUniformWindow 
GS/GIWIN Gps/GpiSetWindow 

GS/GIQAGA Gps/GpiQuerySegment 
Transform 

GS/GIQORG Gps/GpiQuerySegmentOrigin 
GS/GIQSVL Gps/GpiQuerySegmentViewing 
Limits 

GS/GIQTFM Gps/GpiQuerySegmentTransform 
Matrix 

GS/GIQWIN Gps/GpiQueryWindow 


General attribute and control functions: 
GSAM GpiSetAttrMode 
GSCLR GpiClearGraphicsField 
GSDEFE GpiEndDefaults 
GSDEFS GpiBeginDefaults 
GSFLD GpiDefGraphicsField 
GSPOP GpiPop (restore attributes) 
GSQAM GpiQueryAttrMode 
GSQFLD GpiQueryGraphicsField 


x KKK KK KK 
Kx KK KK KK XK 


Correlation and boundary functions: 
GS/GICORS Gps/GpiCorrelateStructure 
GSTAG GpiSetTag 
GSQTAG GpiQueryTag 

Segment manipulation functions: 
GSSATI GpiSetinitialSegmentAttrs 
GSSATS GpiSetSegmentAttrs 
GSSCLS GpiCloseSegment 
GSSDEL GpiDeleteSegment 
GSSEG GpiOpenSegment 
GSSPRI GpiSetSegmentPriority 
GSQATI GpiQuerylnitialSegmentAttrs 
GSQATS GpiQuerySegmentAttrs 
GSQPRI GpiQuerySegmeniPriority 


x KX 
<x K XK 
x XK XK 


Kx KKK KK KK OK 
KK KK KK KK OK 
~x~ KKK KK KK OK 


Metafile support: 
GSGET GpiGetGraphicsData 





Figure 13 (Part 3 of 5). Major Elements of the Presentation Interface 
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Services — Presentation Interface 


Language Element | | MVS | 


GSGETE GpiEndGetGraphicsData 
GSGETS GpiBeginGetGraphicsData 
GSPUT GpiPutGraphicsData 







<x KX 










Picture exchange: 
Picture exchange 

GSLOAD GpiLoadSegments 
GSSAVE GpiSaveSegments 






x & & le 


< x< XK 










Windows (specialized windows and controls for 
Common User Access, including text and entry 
fields): | 
Environment management: 

WMBEEP WinBeep 

WMDISP WinDispatchMsg 

WMDWP WinDefWindowProc 

WMGET WinGetMsg 

WMINIT Winltnitialize 

WMMINT WinSetMsginterest 

WMPEEK WinPeekMsg 

WMPOST WinPostMsg 

WMRCL WinRegisterClass 

WMSCUP WinSetCursorPos 

WMSCUR WinSetCursor 

WMSEND WinSendMsg 

WMSHCU WinShowCursor 

WMSLE WinSetLastError 

WMSSYS WinSetSysValue 

WMTERM WinTerminate 

WMWAIT WinWaitMsg 

WMQCLI WinQueryClassInfo 

WMQCLN WinQueryClassName 

WMQCUP WinQueryCursorPos 

WMQLE WinQueryLastError 
WMQSYS WinQuerySysValue 
WMQVER WinQueryVersion 




























X 
X 
X 
X 
X 
X 
X 
X 
X 
X 
X 
X 
X 
X 
X 
X 
X 
X 
X 
X 
X 
X 
X 









Device management: 
WDCLS DevCloseDC 

(device context) 

WDCRDC WinCreateWindowDC 
WDOPEN DevOpenDC 
WDQCAP DevQueryCaps 








Figure 13 (Part 4 of 5). Major Elements of the Presentation Interface 
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Services — Presentation Interface 


Language Element _Mvs | vM | osi2_ 


Window management: 
WICRT WinCreateWindow 
WIDEL WinDestroyWindow 
WIEWU WinEnableWindowUpdate 
WISCRL WinScrollWindow 
WISHOW WinShowWindow 
WISMPS WinSetMultipleWindowPos 
WISPOS WinSetWindowPos 
WISTXT WinSetWindowText 
WIQVIS WinlisWindowVisible 
WIQRCT WinQueryWindowRect 
WIQTXT WinQueryWindowText 


x KKK KKK KK OK OK 


Presentation space management: 
WPCRT GpiCreatePS 
(presentation space) 
WPDEL GpiDestroyPS 


WPQRY GpiQueryPS 


Dialog and menu support: 
WCCRD WinCreateDlg 
WCCRDB WinDIgBox 
WCCRM WinCreateMenu 
WCDELD WinDismissDlg 


Utility functions: 
WUCOMP WinCompareStrings 
WULOW WinLower (lowercase) 
WUPPER WinUpper (uppercase) 
WUQALP WinlsAlipha 


Programming languages: 
COBOL (GSCP, ...) 
FORTRAN (GSCP, ...) 
C (GpiSetCurrentPosition, ...) 





Figure 13 (Part 5 of 5). Major Elements of the Presentation Interface 
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Query Interface 
Query and report writing services allow one to compose queries of a relational 
data base and to create reports based on the answers. 


Query/report writing is an interactive service. Using an easy, menu-interaction 
approach, users can access and summarize information, and then format the 
results. This means that rather than having to write a program to produce 
answers, a person can merely create and run a query. Results can be obtained 
much more quickly. 


The functions are easy to learn and use. The command set is simple, so one need 
know only a few commands to start becoming productive. Furthermore, online 
assistance guides users so they can make their requests more easily. 


Query and reporting facilities are also available to applications through a program- 
to-program call interface. Applications can thus build and manipulate queries, pro- 
cedures, and report specifications. Results can also be stored and then accessed 
by other applications. 


Query can benefit a variety of users — from data processing experts to those who 
know nothing about data processing techniques. Query lets users concentrate on 
what they are trying to do, rather than how to do it. 


The Interface for Systems Application Architecture 
The interface specification for query is based on an extension of the interfaces 
found in today’s QMF — the Query Management Facility familiar to System/370 
users. 


For more information on the contents of the query commands, see the table on the 
following pages. 
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Services — Query Interface 


The table below lists the interface elements currently in the query interface for 
Systems Application Architecture. 


The table indicates (with an X) which systems already have an IBM licensed 
program announced or available that implements a particular element. 


On MVS and VM, the Query Management Facility products (5668-AAA and 
5668-721, respectively) provide the query interface, with some exceptions. An 
asterisk (*) indicates interface elements that will change in or be added to the 
current QMF. QMF intends to provide this implementation by December, 1988. 
The program call interface element (indicated by **) is planned to be described in 
the Systems Application Architecture query interface reference manual (to be 
available third quarter 1987), and is based on the command interface available in 
QMF today. 


On the Personal Computer, the implementation will be provided by the IBM Oper- 
ating System/2 Query Manager. 


Interface Elements 


Program Call 
Dialog Interface Select Service 


Commands 
Erase: 
Query 
Form (report definition) 
Procedure 
Table 
Export: 
Query 
Form (report definition) 
Procedure 
Table 
Import: 
Query 
Form (report definition) 
Procedure 
Table 
Print: 
Query 
Form (report definition) 
Procedure 
Report 





Figure 14 (Part 1 of 3). Major Elements of the Query Interface 
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Services — Query Interface 


Interface Elements pMvs | VM OS/2 


Run: 
Query 
Procedure 
Save: 
Table data 


Exported Objects 
Query 

Procedure 

Table 

Form (report definition) 


Query Capabilities 
SQL Selection 


Prompted Query 
Table selection 
Column selection 
Row selection 
Row ordering 
Duplicates 
Join columns 


Reporting Capabilities 
Page: 
Heading text 
Footing text 
Blank lines before/after text 
Text alignment 
Numbering of pages 


Column: 
Spacing 
Width 
Heading editing 
Heading separators 
Data editing 
Aggregation: 
Average 
Count 
Maximum 
Minimum 
First 
Last 





Figure 14 (Part 2 of 3). Major Elements of the Query Interface 
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Services — Query Interface 


Sum xX x X 


Breaks on Columns: 
Six levels 
Heading text 
Footing text 
Text alignment 
Blank lines before/after text 
Summary separators 


x KK KK EK 


Final summary: 
Final text 
Text alignment 
Blank lines before text 
Summary separators 


Detail Lines: 
Line spacing 


Variables: 
Page 
Date 
Time 


Print destination 
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